A Thought on Sixels

A while ago I came across a post on Hacker News titled “Are We Sixel Yet”, and was surprised to find out how many people seem to be craving a way to display actual images in their terminals. While I am known for implementing image rendering throughout a vast number of open-source projects, I always use a text renderer that displays the image as color-coded ASCII characters rather than so-called Sixels.

While Sixels offer a way of displaying images – and even gifs and videos – on the terminal, they come with significant trade-offs. Sixels often are limited in terms of color depth. The protocol typically supports only 256 colors, which may be insufficient for applications requiring a broader and more nuanced color palette. A Sixel image viewer might hence not display an accurate representation of the image.

Sixels may also suffer from resolution constraints, particularly when displaying larger or high-resolution images. The protocol may not be suitable for applications that demand intricate details or clarity in images, as the limited resolution can result in pixelation and a loss of visual quality.

Given that the implementation of Sixels, as compared to an ASCII renderer – that is also far from drawing an accurate representation of images – is a lot more complex, it begs the question of whether it is worth the effort in the first place.

While for a terminal “complexity” might be debatable, efficiency is certainly not. Both of these topics have been heavily discussed in the Sixel issue, as well as the PR for my favorite GUI terminal emulator, Alacritty. Even though discussions have been ongoing since 2017, I must admit that I appreciate the hesitation of the Alacritty team when it comes to Sixels, for many of the valid reasons stated in the issue and the PR. In fact, I’d like to take a step back and ask: What are we trying to solve with Sixels in the first place?

These days, terminal emulators are usually running within a graphical environment, that offers the tools necessary to display high-resolution images out of the box. swayimg and imv are two good examples. GUIs aren’t constrained by complexity or efficiency, since the graphical environment in itself is already a huge bucket of complexity, at least compared to something as rudimentary as the console. A terminal emulator’s job is to allow us to interface with the computer in a no-frills manner. The content of that interaction is supposed to be lightweight enough to not only be able to be efficiently processed by the local machine but also be transmittable through low bandwidth TCP/IP or even serial connections. Transmitting and rendering images using Sixels can be bandwidth-intensive, especially for larger or more detailed images. In scenarios where performance is a concern, such as remote connections or low-bandwidth interfaces, the use of Sixels might lead to a significant decrease in performance.

Compatibility is another thing to consider. I like my TUI software to be usable regardless of whether my GUI or GPU-acceleration currently works or not. While I enjoy the benefits of a GPU accelerated terminal emulator like Alacritty, I would certainly not want to depend on command line tools that would require my terminal emulator to run on an actual GUI for them to be functional. So unless tools invest in backward compatibility, the way for example Chafa does, using libsixel and the like sounds like a bad idea.

Ultimately the use of Sixels in terminal applications may disrupt the traditional balance between textual and graphical content. Terminal environments have historically been text-centric, and the integration of graphics through Sixels may challenge this paradigm, potentially causing issues with layout and readability. Text interfaces, especially in the command line, normally strip away distractions, placing a clear emphasis on content. Without the visual noise of imagery, users can concentrate solely on the information at hand.

Hence command line interfaces are renowned for their speed and precision. Power users appreciate the ability to execute complex tasks with only a few keystrokes and without a lot of visual noise. This efficiency is invaluable for developers, system administrators, and other professionals. Text-based systems present only the essential information, avoiding unnecessary clutter.

The beauty of purely text-based interfaces lies in their simplicity and universal accessibility. Embracing this simplicity is not a step backward but a celebration of the timeless efficiency that has been integral to computing since its inception.

Frankly speaking, to me it seems that for most people commenting on the Sixel issue and PR in Alacritty’s repository, this feature is more of a fluke than an actual need. I have yet to read an actual, valid reason why someone would need to be able to display a more accurate representation of images on the command line – especially when they’re seemingly already using a graphical environment, under which Alacritty is run. For a quick glimpse at images, lf, in combination with chafa is a reasonable solution that works in any terminal. For a detailed view, an actual GUI might seem like a better solution.

I fear that the beauty of purely text-based interfaces and pure text as a whole has been forgotten, or maybe not even been experienced by many younger generations in the first place. I’m afraid of the day on which the majority of professionals will be using cloud-connected feature creatures rather than a proper, simplistic terminal that gets the job done.

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Free minix-like kernel sources for 386-AT
Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI>
Date: 5 Oct 91 05:41:06 GMT
Organization: University of Helsinki

Do you pine for the nice days of minix-1.1, when men were men and wrote
their own device drivers?
...

If you’d like to dive deeper into text-centric user interfaces make sure to explore the command-line page and check out some of the programs listed there.